因為正在把過去的手工藝全部轉為 IaC，剛好遇到一題是 SSL 管理相關的，來看看這題怎麼解吧

背景

過往是手動在 console 建立 Self-managed SSL(in GCP Certificate Manager)，憑證名稱是 xxx-2024-09-24，然後有一隻自動化 python 定期建立新的憑證 xxx-2024-11-24，然後重新掛上 load balancer，但這樣的操作沒辦法 IaC 化，每次 自動化 python 更新憑證都會讓我 load balancer 的設定檔跑掉。

思考

• 為什麼要建立新的憑證，而不是直接更新舊的憑證？

  • 如果可以解決，可以一次解決維護自動化 python 的複雜度(免不了還是要更新 SSL )+ IaC

• 有什麼狀況一定要 Self-Managed SSL。

  • 如果沒有，使用 Google Managed 就省了很多功夫

AWS 的經驗

AWS 也有 AWS ACM，用來管理憑證的。好處是 AWS 相關 resources 要使用很方便，還可以用 Amazon E CloudWatch vents (or GCP Cloud Monitoring)在匯入的憑證即將到期時傳送通知 。GCP certification 同理。不管怎樣都會讓 SSL 讓雲端上。

至於用不用 AWS managed 或是 Google managed SSL 差別在於你要信任哪個 CA，假設你信任 AWS，則直接從 AWS ACM 申請會比較方便，也會處理自動續約。但假設你有外部 CA 的需求，就要選擇 import 進去 ACM or self-manage 在 GCP certificate management。

另外，AWS 的憑證是 regional 的，不同 region 要分別匯入。

研究

• 為什麼要建立新的憑證，而不是直接更新舊的憑證？

  首先，我大概可以猜到為什麼前人要有一隻自動化機器重新建立 certification 然後重新掛上 load balancer，因為 Console 沒有這個選項，AWS 跟 GCP 都有同樣貓餅， API 跟介面總是有脫鉤，讓資訊很難統一。

  查了一下資訊，以下指令應該是可以解決的

  gcloud app ssl-certificates update ID [--certificate=LOCAL_FILE_PATH] [--display-name=DISPLAY_NAME] [--private-key=LOCAL_FILE_PATH] [GCLOUD_WIDE_FLAG …]
  

• 有什麼狀況一定要 Self-Managed SSL

  • 等我明天上班確認